…1073, which re-bumps an already-merged pin) (#1075)
* third_party: bump llama.cpp to 6e42864a6, the 3 fork commits merged since 817d0815b
817d0815ba -> 6e42864a6 (fast-forward on 1bit/hrx-vulkan-patched), three commits:
6e42864a6 convert/model: store Zamba2's shared transformer block once per block (engine #1036, fork #203)
b390c2db1 hrx: log a residency decline, so a budget that reshapes the graph is visible (engine #674, fork #174)
c08e9510b src: opt-in per-layer attention q/k dump (LLAMA_ZHA_DUMP_DIR) (fork #179)
None touches the architecture registry, so unlike #1039 there is no registry_build/device_route
consequence (checked: 0 files under registry/ in the three commits). Each commit carries its own build
wiring: #203 and #174 only touch existing files plus one new header, and #179 adds src/llama-zha-dump.{h,cpp}
together with its src/CMakeLists.txt entry.
Behaviour a reader bumping this pin should know about:
* #203 changes what a converted Zamba2 GGUF contains -- a re-convert now writes the shared transformer
block once per block and the loader aliases the rest (ffn_up stays per layer because of the per-layer
MLP adapter). An existing Zamba2 file keeps working on the old path; a new one is smaller.
* #174 adds the hrx placement: decline log (GGML_HRX_HOST_WEIGHT_LIMIT_MB), eight distinct (weight, op)
pairs then one suppression line, plus a verbosity note in the comment.
* #179 is gated on LLAMA_ZHA_DUMP_DIR and does nothing when it is unset.
Closes #1073 as superseded: that PR bumps to 817d0815ba, which main already has (#1039, 518cd93), so its
merge was a no-op.
* registry: record the llama.cpp pin at 6e42864a6 after the bump
tools/registry_build.py --check-pins failed the bump (registry_pins, test 43): a pin moved without
regenerating the registry. Ran it with third_party/llama.cpp at 6e42864a6: hrx 297, npu 7,
architectures 297, mapped 297 -- unchanged from the recorded count, so the three commits add no
architecture. The only change is the recorded pin:
- "llama.cpp (hrx)": "817d0815ba5af..."
+ "llama.cpp (hrx)": "6e42864a628af..."
--check-pins: "records the committed pins"; --check-gaps: "none of the 28 reviewed significant
classes is mapped without a reason".
---------
Co-authored-by: bong-water-water-bong <bong-water-water-bong@1bit.gg>
Follow-up to #202. That PR showed decode wins short prompts (Vulkan) and prefill wins long ones (W4A4, from about 2K tokens). This one serves both from one endpoint.
1bit serve -m MODEL.gguf --long-model MODEL-Q4_0-H32.gguf [--long-from 2048]loads both. A conversation whose first request has at least--long-fromprompt tokens goes to the rotated file on ROCm W4A4, and everything else goes to-m's route.-mbackend (/apply-template+/tokenize, tools included). If that fails, it falls back to about 4 bytes per token.X-1bit-Route: short|long <tokens> <device>is set on every response.--long-model, a rotated-m, a non-llama-server-mroute, and with--laya/--adaptive/--mmproj.tests/long_route.sh(ctest, CI): fake backends, 9 checks. Short and long chats and completions route correctly, a conversation that grows stays put, and the refusals work.hadamard_routeandsmoke_servestill pass.Strix Halo, Qwen3-Coder-30B-A3B, 256 output tokens, effective tok/s (
tools/e2e_bench.py):--long-modelThe
--long-modelrun shared the box with a peer's NPU job, which cost the long side 2-5%. A first run showed 51.6 decode on short prompts. It didn't reproduce in two isolated reruns (79.3-79.8, the same as standalone Vulkan), so it was box contention.🤖 Generated with Claude Code